Mortgage fraud detection systems and methods

ABSTRACT

Mortgage fraud detection systems and methods are provided. A fraud detection system can generally comprise a database operator, a database manager, one or more users, and a database. Database components can be implemented as hardware, software, or a combination of both. A fraud detection method can generally comprise providing a database for maintaining a plurality of records. Data records can be continually received by a database in batchwise or single submission protocols. Records can be compared to determine whether they contain common data in one or more predetermined fields. If records contain common data in one or more predetermined fields, records can be examined for inconsistencies in one or more other data fields. Discovered inconsistencies and magnitudes of inconsistencies can be warning signs of fraud. Results of comparisons can be reported to system users to enable such users to investigate additional circumstances. Other embodiments and features are also claimed and described in the application.

CROSS-REFERENCE TO RELATED APPLICATION & PRIORITY CLAIM

This application is a continuation of U.S. patent application Ser. No.12/174,591, filed 16 Jul. 2008, which claims priority to and the benefitof U.S. Provisional Patent Application No. 61/015,429, filed 20 Dec.2007. Both of said applications are incorporated herein by reference inits entirety as if fully set forth below.

TECHNICAL FIELD

The various embodiments of the present invention relate generally todatabase and information management systems and, more particularly, tofraud detection database systems and methods to assist users to detectmortgage fraud as well as other types of financial fraud that may occurin a financial application process.

BACKGROUND

As shown increasingly by recent financial events, the mortgage industrycontinues to struggle with detecting and managing fraud. Lenders havecome under scrutiny due to relaxed lending policies and vulnerablelending processes exposed to fraudsters. As a result, lenders aregreatly concerned with the continued rise in mortgage fraud. Recentregulatory and political activities have added a new twist tooperational concern—compliance risk. More than 70% of loan originationswere facilitated by mortgage brokers in 2005 and 2006. Fraud committedby industry insiders has caused reported financial losses in excess of$1 billion to date. This figure alone illustrates that current frauddetection solutions are minimally impacting risk exposure for mortgageindustry participants.

Currently, financial industry participants employ a number of systemsthat aim to detect fraud risks in an effort to prevent and mitigatefraud. Unfortunately, conventional systems, such as informationverification tools, have yet to adequately and completely address thevarious types of mortgage fraudulent events. For example, conventionaltools can be used in an attempt to verify information such as propertyvalues, names, social security numbers (“SSNs”), assets, and credithistory provided during an application process. Despite the existence ofexisting, conventional automated tools, however, the mortgage industryand other financial industries continue to encounter a significantnumber of fraud occurrences.

Mortgage fraud typically occurs in two ways: fraud for profit and fraudfor housing or property. Fraud for profit schemes typically result inill-gotten gains from falsified or fraudulent loan transactions andusually involve industry insiders well versed in the funding process.The insiders that are typically parties to fraudulent schemes make itchallenging to uncover fraudulent activities. Financial losses stemmingfrom this type of fraudulent activity can be significant and devastatingto industry participants. Examples of insider contributed fraud include,but are not limited to, illegal flipping, straw buyer scams, equityskimming, and fraudulent property investments.

Fraud for housing or property generally involves factual misstatementsto obtain a property as a primary residence. This type of fraudcontributes to the greatest amount of reported fraud. Commonmisstatements include embellishing salary or income amounts andundisclosed borrowed funds or employment terms. Borrowers are oftencoached by insiders so that reported data is represented more favorablyand appears less risky to lenders.

In addition to the above mentioned mortgage-related fraud schemes, othercommon schemes are typically perpetuated by those participating in suchillegal activities. For example, common mortgage application fraud plotsinclude equity skimming/foreclosure bailout schemes, churning, chunking,shot-gunning, silent second, property flipping, double escrow,straw-buying, air loans, identification theft, asset rentals, mortgageelimination schemes, cash-back schemes, and non-arm's lengthtransactions. These schemes are described below in more detail.

-   -   Equity Skimming/Foreclosure Bailout Schemes: Using money for        reasons other than paying off loans. For example, when a        borrower's property is in foreclosure, a seller purchases the        property for a fee and promises to let the borrower continue to        live on the property if the borrower deeds the property to the        seller. The seller never pays the mortgage, the loan defaults,        and the borrower is forced off the property. The seller walks        away with a fee or with equity. The seller can then choose to        re-mortgage or to abandon the property.    -   Churning: Refinancing the same property repeatedly in a short        period of time. Interest rates, fees, and costs increase with        each refinance. The loan officer can make a lot of money on one        property because of the loan commissions associated with the        constant refinancing. In contrast, lenders and borrowers pay        more for the property than they otherwise would.    -   Chunking: A borrower purchasing multiple properties in a span of        a few days. The concurrent debts do not appear on the borrower's        credit report before the closings. This scheme is often        perpetrated through seminars, or by approaching susceptible        groups, such as those in nursing homes or churches. For example,        a solicitor offers to sell a potential borrower multiple        properties at once, for a fee. The solicitor promises to upkeep        the properties, to lease the properties, and to make all        payments on the applicable loans. After closing, however, the        solicitor disappears with the fees. The borrower is left with        mortgages on multiple properties, and the borrower's credit        history may be destroyed.    -   Shot-gunning: An individual takes out undisclosed multiple loans        on a single property simultaneously and then disappears with the        proceeds. This scheme is often associated with foreign investors        and organized crime.    -   Silent Second: A hidden second mortgage on a property. For        example, a seller gives a borrower a second mortgage that is not        disclosed to the borrow or to the lender of the first mortgage.        To conceal its existence, the second mortgage is usually not        recorded until after the closing. The seller receives the        proceeds of the mortgage, and the borrower has to make the        mortgage payments.    -   Property Flipping: A property sold a short time after a previous        closing on the same property, where the second sale includes a        significant, unwarranted increase in value. While it is legal to        flip a property if appropriate improvements are made, flipping        constitutes fraud when there is a significant value increase        despite only minimal improvements to the property. A fraudulent        appraisal is almost always involved. Illegal flipping can ruin        the value of homes and neighborhoods. Further, lenders can lose        money by providing large loans on over-valued properties.    -   Double Escrow: Two closings on the same property at once. For        example, a borrower buys a property at one price and immediately        sells the property at a higher price. Double escrow is a        property flip with a shortened time frame, and is illegal if all        terms are not disclosed to the involved parties.    -   Straw-buying: Using someone else's credit to secure a loan. The        person whose credit is being used is the “straw buyer.” The        perpetrating parties are often related. For example, if an        individual's brother cannot secure a loan to buy a house, the        individual can offer his own credentials to secure the loan for        his brother. For another example, an individual with good credit        may be approached and offered money to lend his name and good        credit to multiple transactions.    -   Air Loans: All documentation is fabricated to secure a loan.        There is no property and no borrower.    -   Identification (“ID”) Theft: Identity of a borrower or a        mortgage professional is stolen and misused in a loan        transaction.    -   Asset Rentals: Programs where assets, such as bank balances,        cash, and strong credit card lines, are “borrowed” from their        owners to make perspective borrowers appear financially sound.        This scheme appears frequently on the internet. Usually, the        asset “lenders” are compensated in some way.    -   Mortgage Debt Elimination Schemes: Fraudsters present faulty        legal reasons why a particular mortgage or group of mortgages        does not have to be paid. This scheme can be complicated and        frequently appears on the internet. The Federal Reserve Board        explains the scheme here:        http://www.federalreserve.gov/boarddocs/srletters/2004/sr0403.htm.    -   Cash-back Schemes: A lender is deceived by a seller, a buyer, or        both, as to the actual sales price of the property. An inflated        appraisal is often involved to convince the lender to lend too        much on the property. The proceeds are split among the        perpetrators.    -   Non Arm's Length Transactions: Transactions where there is an        undisclosed familial or professional relationship between a        professional in the loan transaction and another involved party.

Mortgage fraud can also occur in ways different from those discussedabove. Indeed other types of encountered examples include:misrepresentations on a mortgage application, inflated appraisals,appraisals with inappropriate comparables, employment and/or incomemisrepresentation (for example, on pay stubs, W-2s, tax returns, orVerifications of Employment), failure to disclose debts and/or otherliabilities, failure to disclose correct employment status, use ofinvalid borrower SSNs, fabricated or misrepresented monthly housingpayments (e.g., rent or mortgage payments), falsified bank statements oraccounts, falsified gift letters, occupancy misrepresentation (e.g.,primary residence vs. investment property), incorrect transaction type(e.g., purchase vs. refinance), borrower and/or seller not properlylisted on property title, misrepresented closing costs, or closing fundsdistributed to unauthorized parties, misrepresented down payments, andunauthorized activity by unlicensed professionals.

As is readily apparent from the above discussion, mortgage fraud occursin many different forms. While some fraud schemes are known, new schemesare hatched by fraudsters in an effort to outpace detection efforts.Fraud schemes and fraudulent misrepresentations are financiallydetrimental not only to those involved, but are also detrimental tocommunities in which subject properties are located and financialmarkets as a whole.

What is needed, therefore, are mortgage fraud detection devices,systems, and methods enabling users to detect fraudulent activity sothat measures can be taken to mitigate fraud risks and stop fraudulentactivities before financial losses occur. It is to the provision of suchfraud detection systems, devices, and methods that the variousembodiments of the present invention are directed.

SUMMARY OF SAMPLE EMBODIMENTS

Briefly described, various embodiments of the present inventiongenerally comprise a fraud detection database, a fraud detectiondatabase system for detecting signs of fraud, and methods for analyzingvarious data resources to detect fraud. Fraud detection may occur inmortgage loan applications as well as many other financial applications(e.g., auto loan, credit card, and many other personal property loans).System users, such as lenders, can submit loan application data to afraud detection system. Loan application data can include informationfrom a borrower's mortgage loan application, such as information enteredon a Uniform Residential Loan Application (Form 1003). Other submittedinformation may also include additional information from lenders andoriginator information, information on brokers, realtors, or appraisersinvolved in the borrower's transaction.

Detecting fraud through a database system can generally compriseproviding a database for storing and/or maintaining a set of records.The records can include various types of financial information. Adatabase operator can access, receive, and/or utilize financialinformation records from a plurality of sources including pre-existingdatabases and/or lending institutions. For example, a database operatorcan configure a fraud detection system to compare a first data record toa second data record to determine whether the two records arepreliminary matches. The first data record may be received from alending institution and the second data record may include pre-existingstored data. Records can be preliminary matches if they have certaindata in common. When records represent loan applications, for example,the data can include any one or more of borrower names, borrower SSNs,and real property addresses for which a mortgage loan is requested.

Preliminary matches can also be compared for inconsistent informationfor fraud detection. If inconsistent information is found, theinconsistent preliminarily matching records may be flagged. Theinconsistent information need not be the same category of informationexamined to determine preliminary matching. For example, two applicationdata sets with the same borrower name or property address but withdifferent appraisal values can be flagged in the database.

Embodiments of the present invention also enable report generation sothat end users can review results of data analysis. In some embodiments,end users may be system subscribers that submitted one or more datarecords to a fraud detection system. Reports preferably show results ofdata comparisons in a format easily and readily understood by end users.In some embodiments, it may be preferable that a database operator canreport whether records were preliminary matches and also whether the tworecords were flagged as inconsistent as well.

Generally, fraud detection embodiments of the present invention areconfigured to receive input data records. Such data input can beprovided by end users who are using embodiments of the present inventionto detect fraud in a financial loan environment. As records are receivedfrom end users, received records can be compared with other records.Comparisons can be made initially upon receipt and also conducted atpredetermined frequencies to continue monitoring for possible fraudulentactivities.

To implement periodic, frequent comparisons, records can undergo one ormore waiting periods between comparisons. Waiting periods can be manytime periods, for example, approximately one day, such that a set ofcomparisons occurs daily for each record. During waiting periods,additional records can be received. At the end of a waiting period, afirst received record can be compared to one or more second records.Based on these new comparisons, reports can be generated forsubscribers. Reports can contain analysis of records submitted after afirst record and during the course of receiving additional records. Thisfeature of embodiments of the present invention enables continuousmonitoring of loan transaction to detect fraudulent activities occurringwithin close time periods. Comparisons can occur periodically byrepeatedly comparing already received records to newly received records.

Periodic comparisons can continue until the termination of apredetermined holding period. During a holding period, received recordscan be retained in a database in an active state, meaning periodiccomparisons continue. The holding period can be, for example,approximately 30 days to approximately 90 days in some embodiments. Forexample, each stored or received record can be compared daily to otherstored or received records for 61 days after the record is submitted toa database operator or entered into the database. Other holding periodlengths may also be used in accordance with embodiments of the presentinvention (for example, ranging between 120 days to twelve months).

On a larger scale, fraud detection system embodiments of the presentinvention can be configured to receive a plurality of records from aplurality of users (e.g., contributory subscribers). Periodically inbulk, or individually as they are received, records are stored in adatabase. After a new record is received, it can be compared to recordspreexisting in the database. A database operator alone or in combinationwith a reporting program can report comparison results to subscriberssubmitting records and to subscribers that records submitted recordspreexisting in the database. The results in such reports can be orderedaccording to a two-tier weighted algorithm.

As used herein, a database operator need not be a human being. Forexample and not limitation, the database operator can be a computersystem, a computer program, one or more modules of a computer system, ora combination thereof. A receiving module can receive records submittedfrom outside sources, including system subscribers or end users. Acomparing module can compare records to each other. A reporting modulecan report results to subscribers. Additionally or alternatively, adatabase operating module can conduct one or more of the tasks performedby the database operator.

Operations of the database operator and of the database system can beperformed by a computer system. Accordingly, such operations can bestored on a computer-readable medium of expression, and performed by acomputer processor. In addition, the various modules discussed hereincan be implemented as hardware, software, or a combination thereof.

In another embodiment of the present invention, a fraud detection systemto detect fraud in a financial loan application process by analyzing aplurality of data from multiple sources is provided. The system cangenerally comprise one or more interfaces (e.g., communicationinterfaces) to receive data, a database, and a processing module. Theinterfaces can be configured to receive data from a plurality of uniquedata sources. The data sources can comprise information received fromunique end users and existing unique databases. The data can comprisedata records comprising at least one of information related to afinancial loan application, parties involved in a loan transaction, andproperty involved in a financial loan. The database can be configured toreceive data from a plurality of unique data sources and to store datawith an identifier configured to distinguish data received from uniquedata sources.

The database can include a processing module or may be operativelycoupled to a processor configured to implement a processing module. Theprocessing module can be configured to determine if one or more datarecords contain one or more matching data fields and flag data recordscontaining one or more matching data fields. Matching information can bestored in a match table, which can be a stand alone memory or associatedwith the database. The processing module can be further configured todetermine if one or more of flagged data records contain differentinformation in one or more other data fields contained in the datarecords. And data records flagged to contain different information canbe stored in the match table.

Fraud detection systems according to the present invention can alsoinclude other features. For example, matching data fields can compriseinformation about property involved in a financial loan and at least aparty involved in a loan transaction. In addition, a system can alsoinclude a reporting module configured to report information concerningdata records containing one or more matching data fields and informationconcerning the flagged data records containing different information inthe one or more predetermined data fields. A reporting module can befurther configured to order information contained in a report at leastpartially based on different information contained in the one or moredata fields and a magnitude of difference. In another aspect, aprocessing module further can be configured to place received datarecords in an active state for a predetermined holding period andperiodically analyze active-state data records relative to existing dataand data received after the active-state data records. Predeterminedholding periods can range from approximately one day to approximatelyone year. In yet another aspect, a processing module can be configuredto determine if one or more of data records contain substantiallysimilar addresses for a real estate property involved in a loantransaction.

In yet another embodiment of the present invention, a method fordetecting fraud in a financial credit or loan application process isprovided. A fraud detection method can generally comprise providing adatabase operatively configured to receive data comprising detailsconcerning a financial credit or loan application and to store receiveddata as one or more first data records. A fraud detection method canalso include configuring a database to receive data from a plurality ofunique data sources and store data with an identifier for distinguishingthe unique data sources. The data can comprise at least one of, one ormore parties involved in a loan transaction, and property involved in afinancial application process. A fraud detection method can also includeproviding a data comparison module operatively configured to flag theone or more first data records containing similar data in one or morepredetermined data fields by storing matching information in a table.Also, a fraud detection method can include configuring a data comparisonmodule to determine if the flagged data records comprising at least onedata field with similar data comprise one or more other data fieldshaving inconsistent data by storing inconsistent data in the table.

Fraud detection methods according to the present invention can alsoinclude other features. For example, a method can include configuring adatabase to provide reports comprising details related to flagged datarecords comprising at least one data field with similar data and detailsrelated to flagged data records comprising data fields with inconsistentdata. A method can also include configuring a database to receive datafrom a plurality of end users and the one or more databases via acommunications network. A method can also include providing a datacomparison module operatively configured to flag data records containingsimilar data in one or more predetermined data fields by determining ifthe one or more data records contain data fields having similar propertyaddress information or similar borrower information.

Fraud detection methods of the present invention can also includeadditional aspects. As an example, a method can include configuring adatabase to provide reports to a user with data ordered based on resultsof a two-tier weighted algorithm. Also, a method can include holdingdata records in the database for a predetermined holding period andconfiguring the data comparison module to compare existing data recordsto data records received after the existing data records at predefinedintervals. A method can also include operatively configuring a databaseto receive lender originated data and user incident report data. Inaddition a method can include configuring a data comparison module toreceive professional license information from one or more existingdatabases to determine if a licensed party involved in a loantransaction is properly licensed and has any past professionalsanctions.

In still yet other embodiments of the present invention,computer-readable media containing code for execution by a processor areprovided. These embodiments can include stored computer readableinstructions to execute a method for detecting fraud and/or implement asystem for detecting fraud. Such code can include instructions forproviding a database configured to receive data from a plurality ofunique data sources and associate received data with an identifier todistinguish the unique data sources. The data can comprise data recordshaving data fields. The data records can comprise information related toa financial loan application, parties involved in a loan transaction,and property involved in a financial loan. Another instruction in thecode can include determining whether one of the data records has a datafield containing common data to at least one other data field containedwithin at least one of the other data records. And another instructionin the code can include determining whether data records having at leastone data field in common have other data fields having disparate data.And still yet another code instruction can include providing a reportcomprising data records based at least partially on the identifier. Thereport can include a listing of data records with data fields havingcommon data and data records containing data fields having disparatedata.

Computer-readable medium embodiments having stored code can also includeadditional aspects. For example, within the code instructions can beprovided such that at least a portion of data records contain mortgageloan application information submitted by unique users and at leastanother portion of the data records contain information obtained frompre-existing databases containing borrower information. Such code canenable a dual pipeline feature as discussed herein. Another exemplaryaspect includes providing code instructions such that data fields arereviewed for common data, including property address information, todetermine if a single property is subject to multiple loan applications.Code instructions can be provided on a medium to repeatedly determine ona pre-determined basis whether data records have data fields containingcommon data relative to other data fields contained within other datarecords, and whether data records having data fields in common also havedata fields having disparate data.

Other aspects and features of embodiments of the present invention willbecome apparent to those of ordinary skill in the art, upon reviewingthe following description of specific, exemplary embodiments of thepresent invention in conjunction with the accompanying figures. Whilefeatures of the present invention may be discussed relative to certainembodiments and figures, all embodiments of the present invention caninclude one or more of the advantageous features discussed herein. Inother words, while one or more embodiments may be discussed as havingcertain advantageous features, one or more of such features may also beused in accordance with the various embodiments of the inventiondiscussed herein. In addition, while discussion contained herein may, attimes, focus on mortgages and mortgage application processes,embodiments of the present invention can also be used in other financialand financial application settings. In similar fashion, while exemplaryembodiments may be discussed below as device, system, or methodembodiments it should be understood that such exemplary embodiments canbe implemented in various devices, systems, and methods.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a block diagram of a fraud detection system accordingto some embodiments of the present invention.

FIG. 2 illustrates an information flow diagram in a fraud detectionsystem according to some embodiments of the present invention.

FIG. 3 illustrates comparing one record to one or more records in afraud detection system according to some embodiments of the presentinvention.

FIG. 4 illustrates a fraud detection method according to someembodiments of the present invention.

FIG. 5 illustrates an information flow diagram for fraud detectionsystem users according to some embodiments of the present invention.

FIGS. 6A-6F illustrate exemplary reports provided by a fraud detectionsystem according to some embodiments of the present invention.

FIG. 7 illustrates a method of fraud detection according to someembodiments of the present invention.

FIG. 8 illustrates a method of an incident submission process accordingto some fraud detection embodiments of the present invention.

FIG. 9 illustrates a method of authenticating and verifying entities andprofessionals involved in a financial application process according tosome embodiments.

DETAILED DESCRIPTION OF PREFERRED & ALTERNATIVE EMBODIMENTS

To facilitate an understanding of the principles and features of thevarious embodiments of the invention, various illustrative embodimentsare explained below. Indeed, embodiments of the present invention aredescribed below for detecting signs of fraud in mortgage loanapplications. Embodiments of the invention, however, are not so limited.Rather, embodiments of the invention can be used to detect fraud or totrack patterns, similarities, or dissimilarities in many fields. Forexample and not limitation, embodiments of the present invention may beused to detect fraud in credit card applications, employmentapplications, and personal property loan applications.

The various embodiments of the present invention assist users indetecting fraud. To assist users in detecting fraud, embodiments of thepresent invention are configured to alert users of potential fraudulentactivity so that users can further investigate the circumstances tomitigate fraud. For example, embodiments of the present invention canenable the mortgage lending community to more accurately determine theauthenticity of the borrower/applicant wishing to obtain a mortgage forreal estate.

In a mortgage fraud scenario that utilizes an identity, fraudsters mayfalsify information related to names, social security numbers, or bothin an effort to create false mortgage transaction and escape detection.By simply transposing a few numbers in a social security number afraudster can assume an identity and begin establishing a historicalrecord of credit as a part of the process for stealing the identity.Additionally, multiple names can be used with a single social securitynumber in an effort to thwart off detection. The alternate names aresubmitted to multiple lenders to avoid being spotted during the process.Lenders are currently vulnerable to this type of attack because there isno system that enables identity variances across multiple transactionswhile verifying information provided by borrowers to lenders in a loantransaction.

As discussed below with reference to exemplary embodiments of thepresent invention, the various embodiments can be used to help mitigatepotential fraudulent activities. The below discussion, while provided invarious sections, should be read as a whole as to applying to thisentire disclosure and the various discussed embodiments. Thus,discussion of one or more features in a certain section can also bepertinent to other features and embodiments discussed in one or moreother sections.

Fraud Detection System & Components Generally

Referring now to the figures, wherein like reference numerals representlike parts throughout the views, exemplary embodiments of frauddetection systems and methods are described in detail. FIG. 1illustrates a diagram showing components of a fraud detection databasesystem 100 according to some embodiments of the present invention. Thedatabase system 100 can generally comprise at least one database manager110, at least one database operator 120, one or more users 130, and adatabase 140. The database system 100 may also comprise one or moreexternal databases 150 for providing additional information to thedatabase 140. The database 140 (and/or the database operator 120 or thedatabase manager 110) can be configured to access one or more externaldatabases 150 to provide additional data to the system 100 to provideenhanced fraud detection capabilities.

As shown by the various arrows in FIG. 1, the illustrated components ofthe system 100 can be networked together. Such networking enables thesystem's 100 components to exchange and share data. For example, users130 are preferably networked with the database operator 120 via anetwork, such as network 160. Network 160 may be a private or publicnetwork. In a currently preferred embodiment, the network 160 caninclude the internet. This configuration enables users 130 to access andutilize fraud detection via an internet, web-based interface. In thismanner, users 130 can access an internet portal to query and search datamaintained in the database 140 to obtain desired information. Asdiscussed in more detail below, the database operator 120 can includevarious processing modules for automated querying of the database andfor reporting results to users. Such reporting can occur based on userdefined search queries and user defined search frequencies. The network160 can also be a private network and also have both public and privatefeatures to enable implementation of varying security protocols.

Although several of the components in the system 100 are shown asstand-alone components, certain of the components may be integratedtogether. For example, one or more of the database manager 110, thedatabase operator 120, and the database 140 can be integrated togetherin a single physical device. In such an embodiment, a single physicaldevice enables a centralized database system 100 at a single location.In addition, one or more of the database manager 110, the databaseoperator 120, and the database 140 can have various components capableof implementing required functionality. For example, the database 140may have one or more data storage units located at one location orlocated at different locations. It should be understood that if one ormore of the database manager 110, the database operator 120, and thedatabase 140 have several components such components can be networkedtogether to enable system functionality.

To implement the fraud detection system 100, each system component canhave various operation functions. For example, the database manager 110can initialize and maintain the database 140. The manager 110 canperform, or cause to be performed, maintenance required by the database140. The manager 110 can also ensure that users 130 execute legal andother documentation desirable for participation in the database system100.

The database operator 120 can be configured to perform database tasks asdesired. For example, the database operator 120 can conduct queries onthe database 140, and in response to the queries, the operator 120 canreceive data from the database 140. Based on data received from thedatabase, the operator 120 can output reports to users 130. The databaseoperator 120 can also accept data submitted by users 130 and cantransfer the submitted data to the database 140. As discussed herein,users 130 can provide data related to or concerning financial loantransaction applications (e.g., mortgage loan information and fraudincident information). The database operator 120 is also preferablyconfigured to enable and accept batches of data from many differentusers 130. The system 100 is contemplated, in some embodiments, as avery dynamic system that is on a real time basis receiving informationfrom many different sources and reporting information to users inresponse to queries. Use of such raw, current data for analysis can helpto enable real time detection of fraud.

The database operator 120 can also be configured to have numerousoperational characteristics. For example, in some embodiments, thedatabase operator 120 can include web service functions to enable aninternet interface between users 130 and the database. Inclusion of webservice functions enables users to access the fraud detection system100, to query the database 140, and obtain data in an effort to learnadditional information about parties to a financial application. Thus,database operator 120 can include various processing modules configuredto search and analyze data according to predetermined data tests. Suchdata tests can compare data from various sources on a wide-scale basisand provide results of the comparisons to users. In some embodiments,the database operator 120 can be, for example, a module of the database140 capable of executing computer code. Additionally, and/oralternatively, the database operator 120 can be a device, a segment ofcode, a computer system adapted to operate in conjunction with thedatabase 140, a database operating module of a computer system, and/or acombination thereof. In currently preferred embodiments, the databaseoperator 120 can comprise a plurality of modules, such as, for example,a receiving module comprising data interfaces for receiving records, acomparing module for comparing records, and a reporting module forreporting results. The database operator 120 can also provide aninterface enabling users to submit and obtain data to the database 140.

Users 130 of the system can be various types of people or entitiesdesiring assistance in detecting fraud. For example, users 130 can besubscribers who are entities, such as mortgage lenders, banks, ormortgage brokers, who subscribe to the database system 100. Users canalso include mortgage bankers, financial lending institutions, realestate agents, appraisers, closing agents, mortgage portfolio investors,home builders, title companies, loan servicers, loan consolidators,accountants, attorneys, banks, direct consumers, other mortgage relatedagencies, and non-mortgage related agencies. Users 130 may also includelaw enforcement personnel and others involved in investigating andprosecuting fraudsters.

In addition to using the system 100 to obtain information about thoseinvolved in financial application processes, users can also provideinformation to the system 100. For example, users 130 can submit recordsto the database operator 120 for submission to the database 140. Suchrecords can include mortgage loan application information (e.g., UniformResidential Loan Application—Form 1003) and also fraud incidentinformation. By accepting information from users, the system canadvantageously obtain information from users who interact withmortgage-related transactions on a daily basis thereby providing adynamic system capable of obtaining current and fresh data. This enablesusers to cross check their data with other users and enables the system100 to consider data from numerous users in an effort to flag possiblefraud conditions.

Users 130 can also receive reports of potential fraud from the databaseoperator 120. Upon receiving such results, users 130 can take steps toinvestigate one or more flagged loan transactions. In currentlypreferred embodiments, the database operator 120 enables users to log into the system 100 and view transactions in the user's internal pipelineand transactions external to the user's pipeline. For example, lender Amay desire to track loan transactions in its pipeline for potentialfraud activity and also track loan transactions external to lender A'spipeline. In this manner, lender A can track loans in the pipeline ofother lenders to see if any loan transactions in lender A's pipelinescontain similar person data to transactions of other lenders. The dualpipeline feature advantageously enables users (such as brokers andlenders) to cross check transactions in their pipeline with transactionsin one or more users' pipelines. As a result, this feature can helpinform users if their clients are also interacting with other users whohave submitted data to the database 140.

The database 140 maintains the records submitted via the databaseoperator 120. The records can comprise data records (or data sets) withvarious data fields. Preferably, the data records have a uniform formatwith uniform data fields. Such uniformity enables the database operator120 to compare and contrast data contained in the data records todetermine existence of possible fraudulent activity. In someembodiments, the database operator 120 and/or the database 140 canvalidate received data records to ensure appropriate format. The volumeof records submitted to the database 140 can be, for example, upwards ofapproximately one thousand per day per user 130. Preferably, thedatabase 140 is scalable to enable receipt of less or more records on adaily basis as desired. The database 140 is preferably configured tomaintain this volume of data. The database 140 is preferably also astorage facility capable of storing large amounts of data.

Provision & Receipt of Data for Investigating Fraud

FIG. 2 illustrates an information flow diagram in a fraud detectionsystem according to some embodiments of the present invention. Forexample, FIG. 2 specifically illustrates a flow diagram 200 ofinformation from various system users 130 to a fraud detection system100. In one aspect, a first borrower 210, borrower 1, applies for a loanthrough a mortgage broker 220. In doing so, borrower 1 210 disclosescertain application information to broker 220. In turn, broker 220discloses this information to a user 130, lender 1 230. Lender 1 230submits to a database operator 120 a record relating to and containinginformation contained in borrower 1's loan application. The databaseoperator 120 received this record and enters the record into thedatabase 140. In some instances, the provided record may be used toupdate or refresh an existing record.

FIG. 2 also illustrates additional users 130 providing data to the frauddetection system 100. Indeed, FIG. 2 shows that a second borrower 240provides mortgage loan application directly through a second lender 250.The second lender 250 can submit borrower 2's 240 applicationinformation to the system 100 via the database operator 120. Thedatabase operator 120 can submit the information to the database 140 asa new record (or an updated or refreshed version of an existing record).While not illustrated, it should be understood that a plurality of users130 can provide information to the fraud detection system 100 at varyingrates as desired. In addition, while certain users shown in FIG. 2 aredirectly communicating with the fraud detection system 100, all users130 can be configured to communicate with other users through the frauddetection system 100.

As users 130 may submit potentially confidential information to thedatabase 140, it may be desired that involved parties enter intoagreements for protection. For example, users 130 can certify that theyunderstand the database system 100 reports tips and leads only, and thatdecisions of whether to accept or deny loan applications should not bemade solely based on such reports. Users 130 can also certify that theiruse of reports will comply with applicable laws and regulations,including the Fair Credit Reporting Act (“FCRA”). Further, it maydesired to have users 130 indemnify the database operator 120 and thedatabase manager 110. The database manager 110 can ensure that theselegal documents are executed.

For any single loan application, the corresponding record submitted tothe database operator 120 by a subscriber 130 can consist of originatorinformation as well as borrower information from a loan application,such as the Uniform Residential Loan Application. Originatorinformation, or originator data, can include data on an entityoriginating the loan application. For example, originator informationcan include the name of a mortgage broker and other information relatedto and unique to the mortgage broker. The following list represents anon-exclusive list of data that may be included in originatorinformation submitted to the database operator 120 in a data record:

-   -   Contract Date    -   Contract Price    -   Realtor Name    -   Realtor License Number    -   Realtor Company Name    -   Originator Name    -   Originator Company Name    -   Originator License    -   Originator Address    -   Appraiser Name    -   Appraiser License Number    -   Appraiser Company Name    -   Appraisal Value    -   Comparable Property Addresses (×6)    -   Comparable Property Values (×6)    -   Closing Date    -   Closing Agent    -   Title Company    -   Escrow Agent    -   Escrow Company

Borrower information, or borrower data, comprises data supplied by theborrower in a loan application. This data can be based on documentationfrom borrowers. The following list presents a non-exclusive list ofborrower information that can submitted by subscribers 130. Not alllisted items need be submitted by every subscriber in every instance,and additional data may be submitted in addition to or in lieu of thelisted items.

-   -   Borrower Last Name    -   Borrower First Name    -   Borrower Middle Name/Initial    -   Borrower Suffix (Jr/Sr/II/III—etc.)    -   Borrower SSN    -   Borrower ITIN    -   Borrower Current Address    -   Borrower Prior Address    -   Seller/Owner Last Name    -   Seller/Owner First Name    -   Seller/Owner Address    -   Subject Property Address    -   Subject Property Parcel ID Number    -   Subject Property—Year Lot Acquired    -   Subject Property—Original Cost    -   Subject Property—Amount of Existing Liens    -   Subject Property—Year Acquired    -   Subject Property—Original Cost    -   Subject Property—Amount of Existing Liens    -   Subject Property—Purpose of Refinance    -   Subject Property—Cost of Improvements    -   Subject Property—Status of Improvements    -   Loan Amount    -   Source of Down Payment, Settlement Charges and/or Subordinate        Financing    -   Current Employer Name    -   Current Employer Address    -   Current Employer Phone    -   Current Employment—Years on this job    -   Current Employment—Position/Title    -   Current Employment—Self-Employment Flag    -   Prior Employer Name (×2 instances)    -   Prior Employer Address (×2)    -   Prior Employer Phone (×2)    -   Prior Employment—Years on job (×2)    -   Prior Employment—Position/Title (×2)    -   Prior Employment—Monthly Income (×2)    -   Prior Employment—Self-Employment Flag (×2)    -   Asset Account—Company Name (×4 instances)    -   Asset Account—Company Address (×4)    -   Asset Account Number (×4)    -   Asset Account Balance (×4)    -   Asset×(Cash or Mkt. Value of all) Real Estate Owned    -   Liability Account—Company Name (×6 instances)    -   Liability Account—Company Address (×6 instances)    -   Liability Account Number (×6)    -   Liability Account—Monthly Payment (×6)    -   Liability Account—Months Left to Pay (×6)    -   Liability Account—Unpaid Balance (×6)    -   Monthly Income—Base Monthly Income    -   Monthly Income—Overtime    -   Monthly Income—Bonuses    -   Monthly Income—Commissions    -   Monthly Income—Dividends/Interest    -   Monthly Income—Net Rental Income    -   Monthly Income—Other    -   Monthly Housing Expense—Rent    -   Monthly Housing Expense—1st Mortgage (P&I)    -   Monthly Housing Expense—Other Financing. (P&I)    -   Monthly Housing Expense—Hazard Ins.    -   Monthly Housing Expense—RE Taxes    -   Monthly Housing Expense—Mort. Ins.    -   Monthly Housing Expense—HOA Dues    -   Monthly Housing Expense—Other    -   RE Owned—Address (×3)    -   RE Owned—Rent, Sold or Pending Sale (PS) Flag (×3)    -   RE Owned—Present Market Value (×3)    -   RE Owned—Amount of Mortgages/Liens (×3)    -   RE Owned—Net Rental Income (×3)    -   Liens/Judgments    -   Bankruptcies    -   Foreclosure    -   Occupancy Status    -   Application Date    -   Purpose of Loan    -   Loan Type    -   Transaction Details—Purchase Price    -   Transaction Details—Alterations, Improvements, Repairs    -   Transaction Details—Refinance    -   Transaction Details—Estimated Prepaids    -   Transaction Details—Estimated Closing Costs    -   Transaction Details—Subordinate Financing    -   Transaction Details—Borrower CC paid by Seller    -   Transaction Details—Other Credits    -   Transaction Details—Cash from/to Borrower    -   Declarations—Outstanding Judgments (Y/N)    -   Declarations—Declared Bankruptcy in past 7 yrs (Y/N)    -   Declarations—Subject of foreclosures, DIL in past 7 yrs (Y/N)    -   Declarations—Party of a lawsuit (Y/N)    -   Declarations—Obligated on any “problem” loan (Y/N)    -   Declarations—Is any part of down payment borrowed? (Y/N)    -   Declarations—Co-maker or endorser on a note? (Y/N)    -   Declarations—Are you a U.S. citizen (Y/N)    -   Declarations—Do you intend to occupy property (Y/N)    -   Borrower Phone Number    -   Amortization Type    -   Credit bureau scores and other bureau data    -   Occupation information    -   Number of homes purchased

Users 130 can provide data to the system 100 in a variety of manners. Insome embodiments, data can be provided on a batch basis and in others ona single record basis. Transfer of batch data can occur at random timesor in accordance with a predetermined data transfer protocol. Forexample, some users may desire to transfer loan application informationon a daily basis as loan transactions are initiated and as loantransactions move through a lifecycle process. Alternative manners ofproviding data to the detection system include submitting incidents offraud data and commenting on existing fraud scenarios. By enabling usersto submit transaction data to the system 100, the system 100 canadvantageously receive fresh raw data to analyze for potential fraudoccurrences and provide reports indicating possible fraud to systemusers.

Analyzing, Testing, & Processing of Received Data

As embodiments of the present invention receive data from users, thedata can be analyzed for possible occurrences of fraud. When such fraudoccurrences are determined to exist for one or more transactions (e.g.,a mortgage loan application), embodiments of the present invention canflag such occurrences so that users can further investigate flaggedtransactions. To investigate possible fraudulent occurrences, frauddetection systems according to embodiments of the present inventiongenerally compare received records to each other in an effort to locatepossible fraudulent activity. In addition, embodiments of the presentinvention can also be configured to access already existing externaldatabases to obtain additional data for comparison to received recordsfrom users. Data comparison of data records can be done on a data fieldbasis to determine if disparate data exists and to determine a magnitudeof difference between data fields.

FIG. 3 illustrates comparing one record to one or more records in afraud detection system according to some embodiments of the presentinvention. As illustrated, FIG. 3 shows a diagram showing how datarecords 310 are compared to other records in a database according tosome embodiments of the present invention. For example, a firstexemplary record 312 can be submitted to the database 140 from a user130 via the database operator 120. After submission, and periodicallyfor a predetermined period, the first record 312 can be compared toother records 310 in the database 140 (other records are shown asRecords 2, 3, 4, through N). By comparing records to each other, frauddetection systems according to embodiments of the present invention candetermine if applicant information differs from existing or otherinformation sources across many numbers of records. By performing suchchecks, the fraud detection system can flag possible fraud occurrencesand report the same to users.

In currently preferred embodiments, comparison of records can includemultiple predetermined checks. For example, comparing the first record312 to another record 310 can generally comprise two checks. Thesechecks can be, but need not be, performed by the database operator 120or a processing module implemented in one or more components in a frauddetection system.

A first check can include determining whether records are matches, orpreliminary matches. Preliminarily matching records 310 can comprisesimilar information in certain data fields. For example, and notlimitation, records 310 with the same borrower name, the same propertylocation or address, and/or the same social security number can bedeemed matches. In alternative embodiments, other data records can bechecked for consistent data in certain data fields (such as those in theabove provided lists). Data records having consistent or matching datain one or more predetermined fields can be flagged for subsequentprocessing. In the event that records do not contain consistent data inone or more predetermined fields, no further comparison may be required.Alternatively, data records having inconsistent data in data fields maybe flagged for subsequent processing.

A second check can determine if records flagged as having consistentdata in one or more data fields have inconsistent data in various otherdata fields. For example, a second check can determine if recordsflagged as matches include inconsistent data, such as contradictory datain such fields as appraisal value, loan amount, borrower SSN, andborrower account/income values. If inconsistent data is found in one ormore of the records 310, the records 310 can be flagged. For example,and not limitation, if a first record 312 includes a borrower income of$55,000, and another record 310 includes a borrower income of $155,000,the two records 310 can be flagged. Such disparate data may be a sign ofa fraudulent occurrence, and in response, the database operator 120 canreturn flagged records 310 to subscribers 130 in the form of reports.Similarly, the database operator 120 can also return matches tosubscribers 130 in reports.

While FIG. 3 may suggest that comparisons are implemented through adirect comparison between records 310, this particular implementation isnot required. For example, and not limitation, digital references to therecords 310 can be sorted over borrower social security numbers,borrower names, property locations, or any combination of these three(as well as the above-listed data fields). Accordingly, determiningmatches between records can include examination of records 310 nearbythe record with respect to the sorted order.

FIG. 4 illustrates a method 400 of detecting fraud according to someembodiments of the present invention. Those skilled in the art willunderstand that method 400 can be performed in various orders (includingdifferently than illustrated in FIG. 4), additional actions can beimplemented as part of a method embodiment, and that some actionspictured in FIG. 4 are not necessary. In addition, it should beunderstood that while certain actions illustrated in FIG. 4 may bediscussed herein as including certain other actions, these certain otheractions may be carried out in various orders and/or as parts of theother actions depicted in FIG. 4. Method embodiments of the presentinvention, such as the one depicted in FIG. 4, may be implemented withthe fraud detection devices and systems discussed herein.

The method 400 generally initiates by receiving data from one or moredata sources. The received data can be stored in one or more databases.Data sources can include one or more contributory users as well as oneor more existing databases. Records may be received on a routinefrequent basis (e.g., daily at a set time or bi-weekly) or as desired(e.g., on a random, unscheduled basis). Indeed, users may submit recordson a nightly basis and a fraud detection system may access and/or obtaininformation stored in one or more other databases as needed. It iscontemplated by the inventors that many data records (e.g., 1000 or moreper day) will be received to enable the various fraud detection methodsto assist in fraud detection. The method 400 can also include verifyingthat a submitted data record is submitted by a valid subscriber bychecking a subscriber registry.

Upon receiving data, the method 400 may also include verifying that thereceived data is compliant with a predetermined data record format.Verification ensures that data originating from various and sometimesdisparate sources, is in a data record format to enable data comparisonand analysis. The specific format of a data record (which can includeany of the data fields listed herein as well as other desired data) isnot important. What is important is that data records have the sameformat or have corresponding data fields. For example, in someembodiments it may be desired to have data records with the same datafields within the data record (e.g., same data record layout). Thisconfiguration can readily enable comparison of data fields within datarecords and accurate, efficient analysis of data fields.

The method 400 can also include an initial review of records. Theinitial review can include iterating through many records as illustratedat 405. In some embodiments active and inactive records may be reviewedwhile in other embodiments only active or inactive records may bereviewed. Records may be changed from active to inactive or vice versadepending on a number of factors, including user selection, datathreshold, or time stamp threshold. In addition, active or inactivestatus may be used to remove and/or add data records in and out of auser's internal pipeline. Records may also be updated during a lifecycleof an application process. The initial review may also include datarecord verification as discussed above. The process of initial reviewpreferably yields a grouping or set of records (e.g., all activerecords) for further analysis.

Further analysis can include searching selected records to determine ifthe records have one or more common data fields. Such data fields may bedeemed critical data fields for fraud detection purposes in that thedata within these fields holds unique significance relative to otherdata fields. As illustrated at 410, the method 400 can include a furtheranalysis to determine whether records have similar property addressinformation. To do this, property address fields in each record arecompared with other records. The method 400 may also include searchingfor records with, for example, similar borrower names or borrower socialsecurity numbers. Still yet, the method 400 can include searching forany combination of critical data fields, in addition to those discussedabove, as desired by a user.

The method 400 can also include standardizing records. Standardizationof records can occur at any time during implementation of the method400. For example, standardization can occur prior to or after recordverification and also prior to of after comparison of records.Standardization can assist in ensuring that data is in similar formatthereby enabling efficient verification and comparison. Standardizationcan include converting received data to a standard form. As an exampleof standardization, address data (e.g., borrower addresses) can beconverted to United States Postal Service format. This way, for example,St. and ST are converted to STREET. As another example, name prefixes(e.g., Mr., Ms., Mrs., etc.) and suffixes (e.g., Sr., Jr., III, etc.)can also be standardized such that common abbreviations and/or spellingsare the same. A used standard for data is not important; rather,ensuring that data is standardized for ease of comparison is importantfor embodiments utilizing data standardization. In some embodiments,data standardization may only occur on some data fields while in others,data standardization may occur on all received data fields. Standardizeddata elements will, preferably, render the data in the same format.

As shown in FIG. 4, the method 400 can include determining whetherpreliminary matches between data fields in various data records arefound. As an example, a fraud detection system can determine whether oneor more matching records are found for a first record as a result ofcomparing predetermined data fields of various data records. Asdiscussed herein, a preliminary match analysis can determine if datarecords have similar SSNs, borrower names, property addresses, or anycombination thereof. If such matching records are found, the method 400may denote that one or more preliminary matches have occurred. If nomatching records are found, the method 400 can proceed to 450. And ifmatching records are found, the method can proceed to process 418 todetermine any potential secondary matches.

As shown, process 450 inquires whether any new of unreviewed recordsexist. If such records exist, the method 400 can initiate again at 405.If no such records exist, the method 400 may end and await receipt ofadditional records and/or user instruction. If a preliminary match toother records is not found, the method 400 can then return that a loanapplication has no corresponding matches. As a result, the method 400may deem a loan application to be a low risk application. In someembodiments, low risk applications may not be searched again and mayalso be flagged for reporting or non-reporting low risk applications tousers depending on user reporting preferences.

As mentioned above, if a preliminary match is found by process 415, themethod 400 can proceed to process 418 to determine potential secondarymatches. As shown, process 418 can include several processes todetermine potential secondary matches. For example, if a preliminarymatch is found across property address fields at 415, the method 400 cancompare each field of matching records. The secondary match analysis418, in some embodiments, is advantageously configured to determine ifany records having preliminary matches (e.g., have matching propertyaddresses) have data fields with disparate information (e.g., differentappraisal values). Thus, process 420 can include comparing records tolocate data fields with disparate information. A matching table can beprovided for storing matching records, or references or pointers to suchrecords. The matching table can also be configured to store informationabout matches, including whether a matching record was found in anexternal database.

After a matching record is found, the method 400 can perform afield-by-field comparison to determine matching records at 425. Toassist in determining matching fields, process 425 can provide matchingindicators in a matching table. That it, if corresponding fields ofrecords match exactly, an indicator of such exact match can be stored.For example, an “E” (denoting exact match) can be stored correspondingto an applicable field and record in a matching table. As anotherexample, if data fields differ, then this can be indicated by storing an“N” (denoting no match) in an appropriate place in a matching table. Andas another example, if data fields vary, a variance indicator can berecorded to indicate a degree of difference. The variance indicator maybe used as a multiplier in a two-tier weighted algorithm as discussedbelow. Typically, a larger data variance in the data yields a largervariance value. For example, for an exact match (“E”), a variance valuemay be a zero (0), and for no match (“N”), a variance value can be athree (“3”). If a particular field contains multiple entries, each entryof the field can be compared to each entry of a corresponding field in amatching record.

The method 400 can also include applying weights to score loanapplication data records at 430. More specifically, one or more datafields in one or more data records can be weighted for importance. Forexample, in some embodiments, data fields of high importance fordetecting fraud can be given higher weights relative to other datafields. Fields containing specific identifying information, such asborrower name or SSN can be provided with high weights, or the highestweights. Only fields with weights greater than zero need be compared forrecords with matching property addresses. Fields can be afforded a zeroweight for strategic reasons or because those fields are not likely toindicate fraud. The weights, in combination with the variance betweencorresponding fields, can determine a relative significance of fraud(e.g., a score denoting potential fraud possibility). A relativesignificance of fraud can be used to determine a likelihood of fraud andalso enable a user to take steps to further investigate. In someembodiments, weights can be implemented with a multiplier value.

As shown in FIG. 4, the method 400 can also include determining a scorefor a data record at 430. Data records as discussed herein can be loanapplications so the method 400 can determine a loan application scoreindicative of possible fraud associated with a loan application. Todetermine a score for particular data records, for each data field in adata record matching a first record, a provided weight value can bemultiplied by a variance to determine a field score. For example, an “E”value can be afforded a lowest variance value for a particular field,while an “N” value can be afforded a highest variance value for a field.Other variance values may also be utilized. Data field scores can besummed for a corresponding data record to determine a data record score.The method 400 can also include providing one or more fraud scenariobased on variance amounts (e.g., determined “N” and “E” results). TableI below illustrates a triggering index that method 400 can implement asan additional testing feature.

The method 400 can also include similar scoring for additional datarecords by analyzing additional record matches at 435. As shown, process435 can determine whether one or more additional records with a sameproperty address, for example, as a first record are found in adatabase. If so, a set of field-by-field comparisons can occur for eachsuch additional record. After all matching records have been found andcompared field-by-field to the first record, the match scores can besummed to determine a total loan score at 440.

The loan score can denote a risk of fraud and also be used to determinea recommended level of due diligence. For example, if a loan score ishigh (meaning it indicates high risk of fraud), a high level of duediligence can be recommended to a user. In a similar fashion of a loanscore is low (meaning it indicates a low risk of fraud), a low level ofdue diligence can be recommended to a user. In some embodiments, loanscores and due diligence levels can be provided on a numbered range(e.g., 1 to 10, or 1 to 100) and/or with “HIGH,” “MEDIUM,” or “LOW”labels. In currently preferred embodiments, loan score and due diligencelevel information can be provided to a user via a web-based interfaceenabling varying use of color indicators (e.g., red, yellow, green,etc.). In addition, in currently preferred embodiments, such informationcan be provided for each loan application in a user's loan applicationpipeline and also summarized based loan score and/or diligence level.Such grouping enables users to focus resources as needed on desired loanapplication groupings in an efficient manner.

As mentioned above, the method 400 can score loan applications to assistusers in detecting mortgage fraud. Based on scoring results, and asshown as 445, the method 400 can also determine an alert status for aone or more data records (or loan applications) in a lenders pipeline.If the loan score is above, below, or consistent with a predeterminedthreshold or threshold range, the method 400 can flag one or more loanapplications to alert one or more users who submitted a loanapplication. The flags can be alerts can be in the form of emails, textmessages, blog entries, or many other communications. Preferably, theflags provide analysis information to users so that users can thendetermine any potential next steps in detecting any fraud associatedwith a flagged data record.

Upon issuing possible alerts for flagged data records, the method 400may continue processing new or additional records at 450. If no suchrecords are located, the method 400 can end or await furtherinstruction. It is currently contemplated that fraud detection methodembodiments of the present invention, like method 400, can reviewnumerous data records in very short time frames all while continuing toreceive additional, new, and/or updated records. Thus, embodiments ofthe present invention are contemplated as being dynamic in that recordreview of raw data continues on numerous records at any one time inaddition to records continuously being added or updated with raw datainformation. Analysis of such raw data in accordance with embodiments ofthe present invention advantageously enables review of real-time datathereby yielding accurate and timely results to users.

Referring back to FIG. 3, the database operator 120 can compare records310 for differences, as described above, and can alert subscribers 130of these differences. The fraud detection system 100 can be configuredto be primarily concerned with inconsistencies between loansapplications, and can also be configured to report multiple similarapplications that are not inconsistent. For example, users might desireto be made aware of loan-shopping. Loan shopping can be suggested bymultiple consistent loan applications for the same borrower on the sameproperty. If a user is aware of loan-shopping, then the subscriber canbe prepared to make a competitive bid for the borrower's business.

As mentioned above, loan applications having certain fields withconsistent data but having certain other fields with inconsistent datacan be a fraud warning sign. Fraudulent loan applications typicallyinclude different borrower data across multiple loan applications forthe same property. For example, and not limitation, records containingthe same borrower name but different appraisal values can be deemedinconsistent. The database system 100 can be capable of furtheranalyzing results, but at the least, the system 100 can preferablyreturn reports indicating flagged records. Upon receipt of such flaggedrecords, users 130 should perform due diligence to determine the causeof flagged inconsistencies.

Inconsistencies between records 310 need not be the result of fraud. Forexample, inconsistencies may arise due to human error, such astypographical errors. If requested loan amounts of a preliminarilymatching pair are listed as $1,295,340 on one application and $1,295,430for another, the subscriber 130 might determine that the inconsistencyresulted from a typographical error. Thus, embodiments of the presentinvention can also be configured to determine a magnitude of differencebetween inconsistent data. Determining magnitudes of difference forcertain data fields can also be indicative of possible fraud. Indeed, auser 130 might perform due diligence to determine whether a magnitudedifference above a certain threshold comports with possible signs offraudulent activity. Indeed, embodiments of the present invention canprovide data elements triggering the variance. This enables users todetermine if a typographical error or a true misrepresentation is acause for the variance. For example, if a submitted appraisal amount is$345,700, a first matched loan triggered a variance to display $354,500,and a second match loan displayed $374,500. In this scenario a user candetermine that both returned variances could be typographical errors dueto transposing of numbers in the returned appraisal amounts.

Even if no typographical error occurred, there may be a plausible, legalexplanation for the variance. For example, suppose preliminarilymatching records 310 include requested loan amounts of $1,295,340 in onerecord 310 and $1,900,000 in the other. While this may be the result offraud, the applications might also have been submitted at differenttimes. The borrower's knowledge with respect to his own funds might havediffered greatly between the submission times. A user 130 can beinformed of this and then perform due diligence to verify the correctrequested loan amount.

In some embodiments of the present invention, users 130 can monitorrecords over a lifecycle of a loan. For example, the database operator120 can continue to monitor records with newer received records tocontinually monitor for possible fraudulent activity. As anotherexample, records 310 can be compared to other records 310 periodicallyfor a predetermined holding period. Indeed, in some embodiments a record310 can be compared to other records 310 daily for a holding period ofapproximately 30 to approximately 90 days. Alternatively, additionalexemplary holding periods can be 61 days and can range from 1 day to acomplete year. Users can modify holding periods per submittedtransactions by providing such search query information to the databaseoperator.

Embodiments of the present invention also enable users to modify loantransactions provided in their respective pipelines. As mentioned above,users can submit information they obtain from applicants to a frauddetection system 100. The fraud detection system 100 can be configuredto maintain various pipelines of applications segregated by users 130.This advantageously enables users to monitor their borrower-specificapplications with an internal pipeline and then applications of otherusers via an external pipeline. In addition, fraud detection system 100embodiments of the present invention enable users to modify transactionsmaintained in their pipelines. For example, as loan transactions nearthe end of a lifecycle or are completed for other reasons, users canprovide this information to the database operator. In doing so, userscan modify the number of transactions contained within their pipeline.And in similar fashion, fraud detection system embodiments of thepresent invention can be configured to provide updated information tousers when data in a data record changes or corresponds with anotherdata record maintained in the database. These features of embodiments ofthe present invention enable users to maintain records in their pipelineas desired and also control how reports are provided to them by thesystem 100.

In other embodiments, and as discussed in more detail below, a frauddetection system 100 can perform credential checks on those involved ina loan transaction. For example, a database operator 120 can verify thatprofessionals included in originator information hold valid credentials.A credentialed list can be maintained in the database 140 for eachsubscriber 130. Alternatively, the database operator 120 and/or database140 can be configured to access one or more external databases to obtaincredential information. A credentialed list can include, withoutlimitation, a list of known mortgage brokers and licensing information.Originator information can be compared to one or more credentialed listsfor one or more users 130. Additionally or alternatively, originatorinformation can be compared to a system credentialed list, which can bemaintained for the benefit of all or a set of the users 130. Iforiginator information fails to match any item of a relevantcredentialed list, users 130 can be alerted.

Reporting Potential Fraudulent Activities for Further User Investigation

FIG. 5 illustrates a flow diagram of information from the frauddetection database system 100 to users 130 according to some embodimentsof the present invention. The database operator 120 can retrieve datafrom the database 140, preferably by way of queries to the database 140.The database operator 120 can send reports to the users 130. Thedatabase operator 120 can also send reports to the database manager 110,which the manager can use to ensure the database system 100 is runningas desired. For example, the database manager 110 can implementadministrative checks and processes to ensure that a fraud detectionsystem is operating as desired.

Reports to users 130 can list all or a subset of preliminary matches,and can list all or a subset of flagged matches. Summary reports canhighlight inconsistent data of flagged matches. As comparisons can beconducted periodically, a user 130 can receive multiple reports on asingle loan application. Each report can be cumulative or,alternatively, each report may list only results of comparisons to newrecords 310. In addition, a report can include a due diligence levelindicating a level of suggested diligence. A report may also include anidentification verification score providing a score indicative ofwhether provided names and biographical information are consistent withvarious other data records.

Fraud detection system embodiments according to present invention candeliver and/or provide reports in electronic form. For example, reportscan be provided in an email format and/or in response to real-timequeries. If results are reported via a computer program in which a user130 logs in to view results, the program can ensure that users 130 havean opportunity to sufficiently view the report. For example and notlimitation, results can remain viewable until a user 130 takes anaffirmative action, such as closing a window or deleting a report in aweb-based interface. Users 130 can choose whether to receive cumulativereports or to receive only new results.

As mentioned above a user 130 can notify the database operator 120 whena loan application is removed from the subscriber's pipeline. If such anotification is made, the database operator 120 can remove theassociated record 310 from the database 140 so that no further reportsto that user 130 include comparisons with one or more associated records310. Other users 130, however, may continue to receive notification intheir reports of inconsistent information between their applications andthe removed loan application. Reports can list results in a particularorder based on preferences of the industry or of individual users 130.

The order can be determined based on a two-tier weighted algorithm foreach element of borrower information in the records 310. Such anindustry-generated algorithm may be derived based on feedback from toplenders and the Mortgage Bankers Association. In a two-tier weightedalgorithm, inconsistencies in certain data elements can be moresignificant than inconsistencies in other data elements in identifyingpotential fraud. For example, an inconsistency in requested loan amountor appraisal value can be more significant than an inconsistency incurrent employer address. Also, a borrower's SSN may be a critical dataelement in determining a valid identity, acquiring credit history,verifying employment and income, etc. Because identity fraud and/ortheft generally requires some level of falsification of an SSNs, SSNscan be weighted as a more important data element (e.g., as a first tierweight). Other data elements can be assigned a different weight (e.g.,as a second tier weight). In reviewing SSNs, for example, embodiments ofthe present invention can determine variance severity for each SSN whenother loans are found matching the property address of a submitted loan.If a number sequence in the SSN is either transposed (which could be SSN“Tumbling”) or different, a weighted multiplier can be assigneddepending on a number of found incidents. In some embodiments, weightvalues can range from zero to thirty, depending on data's importance toa loan transaction.

In some embodiments, it is preferred that significant inconsistenciesappear first in results lists of reports. As such the first tier in theweighted algorithm can consider the significance of the inconsistentdata elements. The second tier can weigh the magnitude of theinconsistency. For example, a requested loan amount difference of$145,000 and $154,000 is less significant than a requested loan amountdifference of $145,000 and $300,000. In some embodiments, when avariance is found for fields assigned a maximum field weight (or aweight above a certain threshold), a high risk alert can be assignedregardless of a total loan score.

A range of due diligence efforts can be undertaken by users 130 based onthe type of inconsistencies shown in reports. For example and notlimitation, if a user 130 sees multiple loan applications for the sameproperty with different monthly incomes, the user 130 may implementtools to research and verify the true income of the borrower. Foranother example, if a user 130 sees multiple loan applications for thesame property but with different borrower names, the cause could be atypographical error. If this is the case, the user 130 might perform duediligence in verifying the correct spelling of the name.

If a user 130 sees multiple loan applications across different lendersfor the same property but with different names, the user 130 mightsuspect a shot-gunning scheme. In that case, the user 130 might verifythe authenticity of the loan application. The database operator 120 canperform preliminary analysis on inconsistent preliminary matches. Forexample and not limitation, reports to users 130 can categorizeinconsistencies to highlight the possibility that certain fraud schemesare underway.

FIGS. 6A-6F illustrate exemplary reports provided by a fraud detectionsystem according to some embodiments of the present invention. The firstrow 610 of the reports in FIGS. 6A-6F lists headings for the items inthe second row 620. The first item of the first row 610 states “LoanID.” Accordingly, the first item in the second row of the first columngives the Loan ID of the primary record 310, the record 310 to which thereport refers. The second item of the first row 610 states “PropertyAddress,” and the second item of the second row 620 gives the propertyaddress on the loan application associated to the primary record. Thenext item of the first row 610 asks for the Loan ID of the primaryrecord 310, which is given in the second row 620 below. The remainingitems ask for Loan IDs of records 310 preliminarily matching the primaryrecord, and the Loan IDs of those records are given below, on the secondrow 620.

Column 630 lists titles of data elements of the primary record 310.Column 640 lists the corresponding data for the primary record. Theremaining columns 650 to the right of column 640 give the inconsistentcorresponding data elements for the preliminarily matching records forwhich Loan IDs are listed in the second row 620.

The database operator 120 can return a preliminary fraud analysis inreports. For example, item 660 gives a possible fraud scheme based on apreliminary analysis of the inconsistencies in the records. For example,a possible fraud scheme can be returned based on the results of a numberof IF-THEN-ELSE tests corresponding to known fraud schemes. These testsare based on data fields contained with data records. Such returnedfraud schemes can include those discussed above and also those discussedbelow in more detail (for example, see TABLE I and associated text).Item 670 gives the potential risk that the records referenced in thereport represent a fraud scheme. Additionally, as shown only in FIG. 6D,the report can list additional useful information 680, such asnon-credentialed and/or sanctioned professionals. So long as reportpresent relevant inconsistencies to subscribers 130, the reports neednot take the same format or report the same set of information as thosereports illustrated in FIGS. 6A-6F.

In addition to the above, the database operator 120 can producecomprehensive aggregated reports from the database 140 for the databaseoperator's own use or for the database manager 110. For example,comprehensive reports can list a number of mortgage applicationsprocessed, the number of different appraisals by a single appraiser, anumber of different appraisals for the same property with differentappraisers, the number of times a potential shotgun fraud wasidentified, the number of times a flip fraud scenario was identified,and many other data. Reporting can also be tailored to user's pipelinesettings. In this manner, for example, reports can include predeterminedformats based on a user's pipeline settings and may only report testingdata of a user's pipeline.

Additional Fraud Detection & Reporting Features

FIG. 7 illustrates a method 700 of fraud detection according to someembodiments of the present invention. Those skilled in the art willunderstand that method 700 can be performed in various orders (includingdifferently than illustrated in FIG. 7), additional actions can beimplemented as part of a method embodiment, and that some actionspictured in FIG. 7 are not necessary. In addition, it should beunderstood that while certain actions illustrated in FIG. 7 may bediscussed herein as including certain other actions, these certain otheractions may be carried out in various orders and/or as parts of theother actions depicted in FIG. 7.

The method 700 may initiate in certain embodiments as shown at 705 byproviding an interface for receiving data. The data can be transmittedto and received into a database for processing in an effort to detectfraud. The data may include financial transaction information including,mortgage loan information. The data may also include informationconcerning borrowers, lenders, and/or entities. Data can be submitted byusers or data can be obtained by accessing one or more databases thatmay be publicly or private databases. In some embodiments, the interfacecan be a web-based interface. Such an interface enables users to submitinformation (e.g., mortgage loan information) for processing via a webbrowser. A web-based interface can also enable transmission ofinformation over the internet. In addition, the interface may beprovided as a software application capable of submitting data over aprivate network. Data can be received in various forms including andranging from receipt of a batch of data records to receipt of a singledata record.

At 705, the method 700 can also include receiving and storing data in afraud detection system database. Data can be stored in various fashions.For example, received data can be stored in various records wherein asingle data record corresponds to a single mortgage loan application.Data can also be stored using various key fields to distinguish datarecords from each other. As an example, data records provided byfinancial institutions (e.g., lenders in a mortgage transaction) may bestored using a key field identifier to distinguish data records betweenfinancial institutions. Such an identifier can be used to implement userpipeline control to one or more users for tracking their own datarecords.

As shown at 715, the method 700 can also include processing transactioninformation to determine a due diligence level associated with loantransactions. For example, a fraud detection system can render identityverification results for each primary applicant/borrower on thetransaction or the highest risk applicant/borrower on the transaction.Each high risk applicant/borrower can be identified by the system anddisplayed in the system interface. High risk individuals can then beassociated with a high due diligence level indicating that a user shouldfurther investigate the applicant/borrower and a respective loantransaction.

As shown at 720, the method 700 may also include processing transactioninformation to determine potential fraudulent activity associated withloan transactions. For example, a fraud detection system can processloan data transaction information for each borrower, applicant, lenderprofessional, and/or company involved in a transaction. In somecurrently preferred embodiments, lenders can view information related totheir mortgage applications via an internal pipeline analysis and alsoview information related to other lenders via an external pipelineanalysis. Enabling lenders to view loan applications in their respectivepipelines relative to loan applications in other lender pipelinesadvantageously enables lenders to determine if borrowers and/or brokersare applying or have applied to other lending institutions. Suchinformation may be useful and desired by lenders in managing riskassociated with mortgage loans.

In addition, a fraud detection system according to embodiments of thepresent invention can perform data validation checks. For example, asystem can process received data to validate information related to theborrower's identity using an identity verification service. Validationcan help determine if alternate information can be found associated withthe borrower information. Such information can determine if a borrowerhas various name aliases as well as social security numbers and names.In a currently preferred embodiment, for example, a fraud detectiondatabase can cross reference a social security number database todetermine if a received name matches the database and also to determineif a received social security number is a valid number (e.g., the socialsecurity number is not on a death list).

As shown at 725, the method 700 can include processing information todetermine compliance with existing laws and regulations. For example, ina mortgage transaction, lending institutions must comply with federallaws and regulations specific to consumer information and theestablishment of relationships with their customers. These regulationsare sometimes referred to as “Know Your Customer” regulations.Regulatory requirements associated with USA Patriot Act, Red Flag Rules(effective November 2008), and FACTA regulations require lendinginstitutions to fairly and accurately know who their consumers are whena relationship is established. Such relationships generally include bankaccount opening, granting of loans, and any other business relationshipthat can materially affect the institution and/or consumer. Mortgagefraud can often be facilitated by simply stealing a consumer's identityor assuming their identity for the purpose of purchasing property ordefrauding a lender for monetary gain. Identity theft is a common fraudincidence reported to local, state and federal agencies. Embodiments ofthe present invention advantageously enable an integrated utility toperform required compliance checks as well as manage the threat offraudsters attempting to use false or stolen identities. To accomplishsuch checks a fraud detection system can access and obtain informationfrom other databases (e.g., the Federal Government's Watch List) andcross check received mortgage loan information with data from theseother databases.

As shown at 730, the method 700 can include processing information todetermine background information for involved entities. This feature ofembodiments of the invention advantageously enables review of loantransaction data related to third parties, industry professionals, andcompanies facilitating a loan transaction. Indeed, some embodiments canaccess one or more other databases (e.g., a proprietary and contributorydatabase) that contain containing information related to professionallicensing, publicly sourced derogatory incident reports, sanction andadministrative action reports, and past or ongoing incidents of allegedfraud and misrepresentation.

As an example, fraud detection systems according to some embodiments canobtain information to verify a professional's credentials and riskassociations by directly searching the contributory database for licensevalidation and status, as well as any inclusion in a reported incidentdirectly, or indirectly. After obtaining and analyzing backgroundinformation for involved entities, the fraud detection system canprovide results to users (as discussed below in more detail). Forexample, the system can return an “OK” or “ALERT” status based onreceived background information. By obtaining and analyzing backgroundinformation, embodiments of the present invention can uncoversrelationships among transaction parties, identify conflicts inprofessional credentials, and enable greater visibility to prior adversebusiness activities or associations that may harm lenders.

As shown at 735, the method 700 can also include providing informationprocessing results to users in various formats. Formats include, but arenot limited to, email alerts and web-page listings. Formats can alsoinclude various reports provided by email and or return web-pagelistings. In addition, exemplary report formats can include line itemresults as a summary of loan transaction data that includes results fromthe processing, matching, and scoring algorithms. Also, the system canenable a user to select specific fields with toggle functionality topresent more detailed information about the loan transaction data andthe processing results. The can also enable interactive userfunctionality to present loan transaction data in configurable formatsthrough filtering, searching, and sorting capabilities. Still yet, thesystem can display a report with detailed validation, verification, andcredentialing processing results related to the borrower/applicant andtransaction professionals and/or companies.

Other reporting capabilities include providing a due diligence levelassociated with a loan transaction and also an identification score. Thedue diligence level can be based partially on an aggregate view of alldata and if certain data inconsistencies appear between reviewed datafields a returned due diligence level can be set to “HIGH RISK” or a“RED ALERT” status. Other due diligence levels can include “LOW RISK” or“MEDIUM RISK levels. Similarly, returned results can include anidentification score providing score information indicative of how aborrower's name checked with other checks. For example, if one databasecontains a name with a different SSN than submitted name, a borrowername identification score may be low indicating that the name issueshould be further investigated. In another example, if one or more otherdatabase checks are performed and a borrower's name information isconsistent among several records a high identification score can bereturned indicating that a borrower's name is consistent with other datarecords.

Fraud Incident Submission Features

FIG. 8 illustrates a method 800 of an incident submission processaccording to some fraud detection embodiments of the present invention.Those skilled in the art will understand that method 800 can beperformed in various orders (including differently than illustrated inFIG. 8), additional actions can be implemented as part of a methodembodiment, and that some actions pictured in FIG. 8 are not necessary.In addition, it should be understood that while certain actionsillustrated in FIG. 8 may be discussed herein as including certain otheractions, these certain other actions may be carried out in variousorders and/or as parts of the other actions depicted in FIG. 8.

The method 800 can initiate at 805 by providing an interface enablingsubmission of fraud related incidents. Indeed, users of a frauddetection system according to some embodiments of the present inventioncan submit information related to fraud for further investigation andpossible inclusion in the fraud detection system's database. Incurrently preferred embodiments, the interface can be a web-basedbrowser form capable of accepting user data entry related reporting afraud related incident. In other embodiments, data forms can betransmitted (e.g., email, FTP, or SFTP) to a fraud detection system foranalysis and review.

The method 800 can continue at 810 by populating data into an incidentreport submission form. Indeed in some embodiments, the system willautomatically load data elements from loan transaction data intospecified fields. For example, an applicant's name will appear in thecorresponding incident submission field. The system also enablesinteraction with users so that additional information (e.g., from one ormore users) can be input into a submission form.

The method 800 can continue at 815 by receiving incident reportsubmission data. Upon receipt, embodiments of a fraud detection systemcan provide the ability to query multiple databases. This enables usersto determine whether those suspected of fraud may have been involved inother reported incidents. For example, the databases include real estateand professional license data directly from the Mortgage Industry DataExchange (“MIDEX”). MIDEX is a repository containingindustry-contributed incidents of fraud and material misrepresentation;publicly sourced information specific to administrative and disciplinaryactions and sanctions; and professional license information. Asmentioned above, a fraud detection system according to some embodimentsenables users to query databases in an effort to verify and adjudicatethe professionals of record associated with the incident.

The method 800 can continue at 820 by providing incident report data forreview. As an example, some embodiments will provide reported fraudincident information for entry into the MIDEX incident submissionprocessing queue. The system can also associate a reported incident toloan transaction data by using a unique identifier that relates the twoentities or the loan transaction data and the incident report. Thus thefraud detection system supports submission of an incident related toloan transactions, transaction parties or information contained in anofficial suspicious activity report. The review process can includeadministrative review of the incident information, direct interactionwith the submitter, data editing of incident information, formal reviewand approval of the completed incident report by the submitter and finaldelivery of the approved incident to a database upload queue forinclusion into the database.

The method 800 can also continue at 825 by receiving follow upinformation related to a reported incident. For example, the system cansupport a request for information and challenge of an incidentsubmission. The challenge process enables an industry professionaland/or company to request incident information naming the requestor. Therequestor can submit information to an administrator via the system forverification and for potential future interaction regarding thesubmitted incident. An administrator can query the database for anyincident reports associated with the requestor. The requestor willreceive the incident information using an approved delivery method. Therequestor is given authorization to respond or rebut informationcontained in the incident. The response or rebuttal is delivered to theincident submitter for review and response. An administrator acts as theintermediary between both parties during the rebuttal process. Duringthe course of the rebuttal process, it may be determined that theincident will remain in tact with no further modifications or therebuttal will be approved by the incident submitter resulting in theremoval of that incident report.

The method 800 can also continue at 830 by providing finalized incidentreport data into a fraud detection system database for review. Forexample, the system can support database modifications to the incidentreport by an administrator. Data modification can include removal ofincident text or the addition of a requestor's response to the originalincident of record. The system can notify submitting entities with arelationship to the requestor as well as other user of interest withincident activity. The system can also notify all entities with aninterest in the named professionals of any new incident activity orupdates to an existing incident report.

Entity & Credential Verification Features

FIG. 9 illustrates a method 900 of authenticating and verifying entitiesand professionals involved in a financial application process accordingto some fraud detection embodiments of the present invention. Thoseskilled in the art will understand that method 900 can be performed invarious orders (including differently than illustrated in FIG. 9),additional actions can be implemented as part of a method embodiment,and that some actions pictured in FIG. 9 are not necessary. In addition,it should be understood that while certain actions illustrated in FIG. 9may be discussed herein as including certain other actions, thesecertain other actions may be carried out in various orders and/or asparts of the other actions depicted.

As shown, the method 900 can initiate by receiving names of entitiesinvolved in a loan transaction. Entities can include people, names ofbusinesses, and companies. People may include borrowers, lenders,brokers, and realtors. By receiving this information, fraud detectionsystems according to the present invention can perform background andcredential checks on the received information. Indeed, at 910, themethod 900 may include comparing received information with recordsalready existing in the database. The result of such checks can provideinformation beneficial to users thereby enabling users to obtainbackground information on those involved in a loan transaction.

The method 900 can also include obtaining information from otherexisting databases at 915. These databases can include private andpublicly available databases. The existing databases can be managed bythird parties and they databases can be located distant from a frauddetection system. The existing databases can, for example, be managed bygovernmental or industry licensing groups and contain entity licensingand/or sanction information. Such features enable users to query adatabase for authorized and credentialed professionals when a loantransaction is commenced. In addition, a fraud detection system enablingsuch entity checking can also facilitate queries to credentialedprofessionals list owned by the user of the system. In some embodiments,fraud detection systems will upload information about a individualprofessional, as it is presented to the system user. The system can thenengage a workflow of data service calls and return specific informationrelated to, for example, professional license status, incidents, OFACcompliance, criminal background, and a synthetic identity check.

After obtaining entity background information from existing databases,users and/or a fraud detection system can compare the receivedbackground information to received loan transaction information toperform background checks at 920.

The method 900 can also include reporting entity information to users at925. For example, fraud detection system embodiments can be configuredto present a return list to users for selection when prompted to inputinformation about a loan transaction professional. The process forprofessional credentialing may be a workflow of choreographed dataservices that will perform a series of checks and verifications,resulting in a “PASS/FAIL” score for an entity. For each professionalcredential, the system may require a minimum amount of data criteria toprovide results and to assign a “PASS/FAIL” score to be compiled for theoverall score. Embodiments can also include providing a credentialedprofessional list with access to system detail reports and an exceptionlist that contains professionals and/or companies that have beenidentified as not credentialed to do business. Additional embodimentscan also enable uploads of professionals not credentialed to do businesswith the system user, by the system user.

Fraud Scheme Analysis & Determination

As mentioned above, embodiments of the present invention can be used toidentify a potential fraud scheme. The identification can be determinedby analyzing results of data field analysis and comparison. For example,the inventors have discovered that by analyzing matching characteristicsof certain data fields (e.g., data fields have data that matches or doesnot match), one or more potential fraud schemes can be provided to auser. Matching characteristics can also include analyzing the “N” (nomatch) and “E” (exact match) processes discussed above. The belowprovided table (TABLE I) provides a series of test scenarios forimplementing a fraud scheme analysis process in accordance with someembodiments.

TABLE I Fraud Scheme Shot- Double Straw Data Fields Analysis MultipleFlipping Gunning escrow Churning Chunking buyerLOAN_BORROWER.CLN_NAME_LAST * N E E E E N LOAN_BORROWER.CLN_NAME_FIRST *N E E E E N LOAN_BORROWER.SSN * — — — — — E ORIGINATOR_COMPANY E — E N EE LASTNAME_ORIGINATOR E — E N E E FIRSTNAME_ORIGINATOR E — E N E EAPPRAISAL_VALUE N — N N N N LASTNAME_APPRAISER E — E E E EFIRSTNAME_APPRAISER E — E E E E APP_DATE N N N N N NLOAN_SELLER.LASTNAME * N E N — E E LOAN_SELLER.FIRSTNAME * N E N — E ECLOSE_DT 30 30 5 30 5 60 Additional cross-field comparisons borrower ==borrower == originator == seller seller seller

As shown in TABLE I, embodiments of the present invention can beconfigured to review the results of a matching analysis for various datafields. Based on the analysis, a potential fraud scheme can be providedto a user. For example, if a no match result is returned for loanborrower name, appraisal value, application data, and loan seller namein concert with a match for originator company and name and appraisername information, this information can indicate a possible flippingfraud scheme. As a result, embodiments of the present invention canreturn this information to a user so that a user can furtherinvestigate. Shot-Gunning, double escrow, churning, chunking, andstraw-buyer alerts can be similarly returned to users if a matchinganalysis is in line with the above table entries. Given the dualpipeline features of the present invention, possible fraud scenarios canbe returned for both a user's internal pipeline and also for recordsexternal to a user's pipeline.

The embodiments of the present invention are not limited to theparticular formulations, process steps, and materials disclosed hereinas such formulations, process steps, and materials may vary somewhat.Moreover, the terminology employed herein is used for the purpose ofdescribing exemplary embodiments only and the terminology is notintended to be limiting since the scope of the various embodiments ofthe present invention will be limited only by the appended claims andequivalents thereof.

For example, embodiments of the present invention can include additionalfeatures as described below. For example, a processing module can beconfigured to separate loan transaction information for review by usersinto multiple pipelines using an identifier configured to distinguishusers. Also, a processing module can be configured to separate loantransaction information into an internal pipeline comprising loaninformation associated with a first lender and an external pipelinecontaining loan information associated with lenders other than the firstlender. In addition, a processing module can be configured to associateat least one of a due diligence level and identification score with oneor more data records. Also, a processing module can be configured todetermine if one or more data records complies with financial laws andregulations. Still yet, a processing module can be configured tomaintain one or more data records in an active pipeline for apredetermined amount of time, the one or more data records in the activepipeline being associated with a single lender. And yet another aspectcan include providing users information about one or more data recordsrelating to mortgage applications at predetermined stages of themortgage applications. Also, in accordance with some embodiments, datarecords can have a uniform format such that the processing module cancompared a data record to another data record to determine consistenciesand inconsistencies.

Other aspects of embodiments of the present invention can includeadditional features as described below. For example, a method caninclude receiving fraud incident data information and storing suchinformation as a data record. A fraud detection method can also includereceiving a query based on or more data fields and to return datarecords responsive to the query. Still yet, a processing module can beconfigured to monitor one or more data records for a predeterminedperiod of time and provide reports detailing any changes in the one ormore data records. A processing module can be configured to providereports comprising information about a mortgage application proximate atleast one of a pre-funding application stage, a loan funding stage, aninvestor servicing stage, and a loan servicing stage.

Embodiments of the present invention can still have other features. Forexample, some embodiments can be configured to validate the one or moredata records to ensure that the one or more data records comprise databased on a predetermined data format. Some embodiments can also beconfigured to receive updated data pertaining to one or more datarecords and providing administrative operating reports comprisingoperational information. Such operational information can includedatabase operational status, user interaction information, usersubmitted information, and other administrative data functions asdesired. As discussed herein, embodiments of the present invention canreceive information from unique users, which can comprise lenders,brokers, and borrowers. Embodiments can also include at least onewebserver operatively configured to provide data interfaces and/orinternet portals for use in communication networks. Also, embodiments ofthe present invention enable users to customize reports provided tothem. For example, a reporting module can be operatively configured toreceive report format information from a user and to provide reportinformation to a user based at least partially on the received reportformat information.

Therefore, while embodiments of the invention are described withreference to exemplary embodiments, those skilled in the art willunderstand that variations and modifications can be effected within thescope of the invention as defined in the appended claims. Accordingly,the scope of the various embodiments of the present invention should notbe limited to the above discussed embodiments, and should only bedefined by the following claims and all equivalents.

1. A fraud detection system to detect fraud in a financial loanapplication process by analyzing a plurality of data from multiplesources, the system comprising: one or more interfaces configured toreceive data from a plurality of unique data sources, the datacomprising data records comprising at least one of information relatedto a financial loan application, parties involved in a loan transaction,and property involved in a financial loan; a database configured toreceive data from the plurality of unique data sources and to store thedata with an identifier configured to distinguish data received from theplurality of unique data sources; a processing module configured todetermine if one or more of the data records contain one or morematching data fields and to flag data records containing the one or morematching data fields by storing match information in a table; and theprocessing module further configured to determine if one or more of theflagged data records contain different information in one or more otherdata fields contained in the data records and storing informationcorresponding to differences in the table.
 2. The fraud detection systemof claim 1, the one or more matching data fields comprising at least oneof information about property involved in a financial loan and at leasta party involved in a loan transaction.
 3. The fraud detection system ofclaim 1, further comprising a reporting module configured to report atleast one of information concerning the data records containing the oneor more matching data fields and information concerning the flagged datarecords containing different information in the one or morepredetermined data fields.
 4. The fraud detection system of claim 3, thereporting module further configured to order information contained in areport at least partially based on different information contained inthe one or more data fields and a magnitude of difference.
 5. The frauddetection system of claim 1, the processing module further configured toplace one or more received data records in an active state for apredetermined holding period and periodically analyze active-state datarecords relative existing data and data received after the active-statedata records.
 6. The fraud detection system of claim 5, wherein thepredetermined holding period ranges from approximately one day toapproximately one year.
 7. The fraud detection system of claim 1,wherein the one or more data sources comprise at least one ofinformation received from unique end users providing data to the one ormore data interfaces and information received from existing uniquedatabases operatively coupled to the one or more data interfaces.
 8. Thefraud detection system of claim 1, wherein the processing module isconfigured to determine if one or more of the data records containsubstantially similar addresses for a real estate property involved in aloan transaction.
 9. A method for detecting fraud in a financial creditor loan application process, the fraud detection method comprising:providing a database operatively configured to receive data comprisingdetails concerning a financial credit or loan application and to storereceived data as one or more first data records; configuring thedatabase to receive data from a plurality of unique data sources andstore the data with an identifier for distinguishing the unique datasources, the data comprising at least one of, one or more partiesinvolved in a loan transaction, and property involved in a financialapplication process; providing a data comparison module operativelyconfigured to flag the one or more first data records containing similardata in one or more predetermined data fields by storing matchinginformation in a table; and configuring the data comparison module todetermine if the flagged data records comprising at least one data fieldwith similar data comprise one or more other data fields havinginconsistent data by storing inconsistent data in the table.
 10. Thefraud detection method of claim 9, further comprising configuring thedatabase to provide reports comprising at least one of details relatedto the flagged data records comprising at least one data field withsimilar data and details related to the flagged data records comprisingdata fields with inconsistent data.
 11. The fraud detection method ofclaim 9, further comprising configuring the database to receive datafrom a plurality of end users and the one or more databases via acommunications network.
 12. The fraud detection method of claim 9,wherein providing a data comparison module operatively configured toflag the one or more data records containing similar data in one or morepredetermined data fields comprises determining if the one or more datarecords contain data fields having similar property address informationor similar borrower information.
 13. The fraud detection method of claim9, further comprising configuring the database to provide reports to auser with data ordered based on results a two-tier weighted algorithm.14. The fraud detection method of claim 9, further comprising holdingone or more of the data records in the database for a predeterminedholding period and configuring the data comparison module to compareexisting data records to data records received after the existing datarecords at predefined intervals.
 15. The fraud detection method of claim9, further comprising operatively configuring the database to receivelender originated data and user incident report data.
 16. The frauddetection method of claim 9, further comprising operatively configuringthe data comparison module to receive professional license informationfrom one or more existing databases to determine if a licensed partyinvolved in a loan transaction is properly licensed and has any pastprofessional sanctions.
 17. A computer-readable medium having computerreadable instructions stored thereon for execution by a processor toexecute a method for detecting fraud, the fraud detection methodcomprising: providing a database configured to receive data from aplurality of unique data sources and associate received data with anidentifier to distinguish the unique data sources, the data comprisingdata records having data fields, the data records comprising at leastone of information related to a financial loan application, partiesinvolved in a loan transaction, and property involved in a financialloan; determining whether one of the data records has a data fieldcontaining common data to at least one other data field contained withinat least one of the other data records; determining whether data recordshaving at least one data field in common have other data fields havingdisparate data; and providing a report comprising data records based atleast partially on the identifier, the report further comprising alisting of data records with data fields having common data and datarecords containing data fields having disparate data.
 18. Thecomputer-readable medium of claim 17, wherein at least a portion of thedata records contain mortgage loan application information submitted byunique users and at least another portion of the data records containinformation obtained from pre-existing databases containing borrowerinformation.
 19. The computer-readable medium of claim 17, wherein thedata field reviewed for common data comprises property addressinformation to determine if a single property is subject to multipleloan applications.
 20. The computer-readable medium of claim 17, furthercomprising repeatedly determining on a pre-determined basis whether oneof the data records has a data field containing common data to at leastone other data field contained within at least one of the other datarecords and whether data records having at least one data field incommon have other data fields having disparate data. 21-45. (canceled)